Meeting date: 20 jun 2006
Members (asterisk for those attending):
*Arpad Muranyi, Intel Corp.
*Bob Ross, Teraspeed Consulting Group
*Todd Westerhoff, Cisco Systems
*Mike LaBonte, Cisco Systems
Paul Fernando, NCSU
*Barry Katz, SiSoft
*Walter Katz, SiSoft
*Ken Willis, Cadence Design Systems
*Ian Dodd, Mentor Graphics
*Lance Wang, Cadence Design Systems
*Richard Ward, Texas Instruments
*Doug White, Cisco Systems
Sanjeev Gupta, Agilent
*Joe Abler, IBM
John Shields, Mentor Graphics
*Ambrish Varma, NCSU
*Nilesh Kamdar, Agilent
*Hemant Shah, Cadence Design Systems
*Jillin Tan, Cadence Design Systems
*Shangli Wu, Cadence Design Systems
*C. Kumar, Cadence Design Systems

-------------
Review of ARs:

- no ARs from last week

-------------

Introduction of all participants.

Hemant Shah introduced the Cadence SerDes solution proposal.
- High level discussion for now.
- Technical discussion will continue next week.

Joe Abler presented the SerDes channel design challenges.

Kumar presented the solution proposal.
- Impulse response characterization is fed into channel simulator.

Joe Abler summarized.
- We are talking about:
  - Convolution engines that can simulate millions of bits.
  - Hooking algorithmic processing into these simulations.
- Making models for convolution simulation:
  - Circuit models are used for characterization.
  - Get the impulse response for each scenario from circuit simulator.
  - DLLs store the models specifically for convolution simulation.
    - Designs are highly linear.
    - Only need 1 characterization.
- Can't AMS do this?
  - TI uses AMS for design:
    - Could characterize the AMS model to produce a DLL anyway.
  - IBM uses C and Matlab for design.
  - Kumar: AMS has limited capability,
    - AMS is an extension of device modeling.
    - It has no vector processing.
    - It is unnatural to describe algorithms in AMS.
  - Ian: TI is using it
   - Richard: it comes down to performance
- What is in the DLL?
  - It's a DSP, the output depends on the input.
  - Changing the number of serdes taps requires new characterization.
- Slide 23 shows a particular platform implementation:
  - This may be confusing.
  - It doesn't require a convolution engine.
- All of our simulators have existing DLL-like APIs - why a new one?
  - Existing APIs are proprietary and incompatible.
  - Tools like Matlab are completely different, not just voltage and current.
  - Waveforms in the DLL can be voltage or anything else.

How should IBIS be involved?
- Arpad: Afraid to standardize the channel analysis technique.
- Walter: EQ needs to be looked at independently:
  - SerDes driver model only needs 9 numbers.
- We should standardize as little as possible to avoid slowing down development.
  - Adding API models as [External Circuit] in IBIS would suffice.
    - Current IBIS spec has a limited set of ports.
    - Needs to support vector data, for example.

Ian: Cadence is proposing a System Design Paradigm
- Why not SystemC, which Cadence and Mentor support?
  - Does SystemC have simulator API standards?
  - We need someone to explain what SystemC has for APIs.

Compiled C code offers little protection (Ian has proven it).
- Think of compiled code as a determent on top of an NDA.

Next week discuss details of implementation in IBIS:
- Cadence hosting the call, same people expected.
- Joe and Todd unavailable next week.

The presentation used for this meeting will be sent out.

-------------
Next meeting: Tuesday 27 Jun 2006 12:00pm PT